.specify/v1-reference/NYM_IDENTITY.md (2)

130-136: Privacy model is sound; consider clarifying collision implications.

The privacy considerations are well-reasoned:

• ✅ Deterministic generation without reversibility
• ✅ Trade-key derivation ensures privacy mode isolation
• ✅ Acknowledged collision acceptance for single-trade context

Minor style fix: Line 135 should be "Trade-key-based" (hyphenated) per the static analysis hint.

Optional enhancement: With ~3,910 combinations, the birthday paradox suggests a 50% collision probability with approximately 63 simultaneous users across all trades in the network. While the document correctly states this is acceptable for visual distinction within a single trade, it might be worth noting that collision rates will be higher in busy deployments. This doesn't impact security but helps set expectations for visual uniqueness.

📝 Proposed clarification

-4. **Trade-key based**: Nyms are derived from trade keys, not identity keys. In privacy mode, each trade uses a different key, so the same user gets different nyms across trades.
+4. **Trade-key-based**: Nyms are derived from trade keys, not identity keys. In privacy mode, each trade uses a different key, so the same user gets different nyms across trades. Note: With ~3,910 combinations, collisions become likely as the network grows (50% probability with ~63 concurrent participants across all active trades), but this is acceptable since nyms are only used for visual distinction within a single trade, not for authentication.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.specify/v1-reference/NYM_IDENTITY.md around lines 130 - 136, Change the
phrase "Trade-key based" to the hyphenated form "Trade-key-based" in the Privacy
Considerations section (the line describing that nyms are derived from trade
keys). Locate the sentence referencing trade-key derivation (the one starting
with "Trade-key based") and replace it with "Trade-key-based" to satisfy the
static analysis/style hint.

---

137-154: Clarify implementation boundary for icon and color selection.

The implementation notes suggest word selection happens in Rust, but icon and color selection could be in either Rust or Dart (line 148: "can also be in Rust if preferred"). This creates ambiguity for implementers.

Recommendation: For consistency, testability, and determinism guarantees, all deterministic selection logic (words, icons, colors) should be implemented in Rust:

• Ensures identical behavior across platforms
• Makes cross-client compatibility easier to verify
• Concentrates deterministic logic in one tested layer
• Dart only handles rendering the already-selected components

📋 Proposed clarification

 ### Dart Side
-Only the avatar widget needs Dart implementation:
+Only the avatar widget rendering needs Dart implementation:
 - Receives the generated nym string from Rust
-- Handles icon/color selection (can also be in Rust if preferred)
+- Receives the selected icon identifier and color value from Rust
 - Renders the CircleAvatar widget
+
+**Recommendation**: Implement icon and color selection in Rust alongside word selection to ensure determinism is testable and consistent across all platforms.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.specify/v1-reference/NYM_IDENTITY.md around lines 137 - 154, The notes are
ambiguous about whether icon/color selection belongs in Rust or Dart; make
deterministic selection fully handled in Rust alongside the existing nym
generation (i.e., extend the Rust-side API exposed via flutter_rust_bridge to
return the nym string plus the chosen icon identifier and color), and update the
Dart avatar widget to only accept the nym, icon id, and color and render the
CircleAvatar; also update tests referenced in NYM_IDENTITY (nym generation,
icon/color determinism, and visual regression inputs) to assert Rust-produced
words, icon ids, and colors are stable and consistent across platforms.